>Question I have is - how does doing all those saves and restores in >SPARC assembler result in the user being able to modify the ucred struct >in a running program without privs to modify memory directly? I suppose >a workaround would be to (cringe) disable ps temporarily, or for those >who can, modify it to not show that address info and and deny the info >needed to find the ucred struct in a running program, at least until a >real fix is devised. Perhaps another idea would be to devise some test >to result in the process being killed when a user overflows the register >windows (hell, I'm really groping here, so bear with me). I was wondering that too; perhaps there is some obscure bug in the SPARC chip itself that allows the access without flagging an exception? (grope grope, i know virtually NOTHING about sparc assembler and the chips internals) However, as a data point, i tried the above referenced Sparc code on two different Sparc Classic machines: one running Solaris 2.2, the other running Solaris 2.3, with the kernel jumbo patches applied. The results were exactly as i expected to get on both machines: % ./read 0x<insert address here> Segmentation fault (core dumped) Code was compiled with GCC 2.4.5. Adb showed me that GCC did not do anything funny to the assembly source; the rdmem routine was assembled as given. The seg fault occured at the "restore" instruction in the following section of the provided code: btst 4, %o0 andn %o0, 7, %fp restore So. Has anyone found that the provided code *does* do what the message implied? what were your test conditions? -phil servita, FTP Software, Systems Dept.